<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>PrettyProlog</title>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<meta name="generator" content="Emacs">
<style type="text/css">
@import url("style.css");
</style>
</head>
<body>
<div id="container">
    <div id="header">
        <h1>PrettyProlog</h1>
    </div>
    <div id="content">
	<p align="left">
	    <h3 align="left">Introduction</h3>
	    Learning Prolog can be tough for beginners, especially if they're already accustomed to imperative languages. Still, Prolog is not only useful in passing the Artificial Intelligence exam; Prolog is a Good Thing[<a href="biblio.html#1">1</a>], and more, Prolog is fun. Once I myself overcome the initial difficulties with the language, I really enjoyed it, and was amazed by how such power can be obtained with unification and solving algorithms which are quite simple. I started thinking about implementing them myself, and the idea of PrettyProlog slowly was formed.<br />The main objective of the PrettyProlog software is to aid people in understanding the mechanisms at the core of Prolog, providing an interpreter of a rather minimal subset of the language and various debugging/inspection tools, like a Stack Viewer and an SLD Tree Viewer. (The secondary objectives of the software are, of course, getting me a degree and giving me much joy &amp; pain in developing it).
	    <h4 align="left">Design goals &amp; choices</h4>
	    PrettyProlog has been designed to be simple, modular, and easily expandable.<br />
	    For example, the core engine has an event-driven interface that makes it easy to deeply control the solving process without subclassing the engine itself or re-writing engine methods.<br />
	    Also, as a design choice, simplicity has been favoured against strong encapsulation when needed. So for example, nothing prevents the programmer to corrupt the engine's stack during goal solving. The documentation (Javadocs) explicitly states when it is unsafe to modify a data structure returned by some method.
	    <h4 align="left">Development methodology</h4>
	    Since the requirements were only loosely defined through informal conversations with Prof. Mascardi, an agile, prototype-based development model was used. The goal was implementing core features first and then grow incrementally from there, trying to always have running code at the end of each development phase, so to be able to run tests and if necessary re-adapt requirements. I believe this method proved to be overall good, but I also found it has some negative aspects. In particular, the pros and cons of agile methodology I have encountered in this project are:
            <ul>
              <li>
               <strong>Pros:</strong>
               <ul>
                <li><strong>Exploratory programming.</strong> By not having a fixed design, I was able to explore the problems and try different solutions, and then choose the one I thought fitted best.</li>
                <li><strong>Constant motivation.</strong> This is not usually taken into account, but having a running program to tinker with since the early phases of development keeps the programmer interested in the project and develops a strong sense of commitment to it.</li>
               </ul>
              </li>
              <li>
               <strong>Cons:</strong>
               <ul>
                <li><strong>Endless Beta status.</strong> Since there is no fixed plan, you can't check against it to see what percentage of the project you have implemented, or to decide whether a feature is completed or not. In this sense the program is always in Beta phase - there's no sharp distinction between the prototype and the final product.</li>
                <li><strong>Temporary hacks become permanent.</strong> Sometimes it happens that something is first conceived as an &quot;hack&quot;, a temporary solution to have a working prototype, and then it proves to be useful and is kept till the final version. It is the case of the Parser class, which now, <i>a fortiori</i>, I realize I should have done differently, but to change it would require great work at this point.</li>
               </ul>
              </li>
            </ul>
	    <h4 align="left">Why start from scratch?</h4>
	    PrettyProlog has been developed from scratch, without reusing any existing Prolog implementation. Several open-source prologs were examined, but I felt none satisfied completely the need for a stack-based, easily expandable and customizable Prolog system, because they're all targeted to professional users and thus contain many additional features and optimizations that make them quite complicated. By following this approach, a number of ad-hoc design choices could be made, that make PrettyProlog a very &quot;open&quot; piece of software, in terms of customization and expandability/reusability.
	    <h4 align="left">Details</h4>
	    For more detailed info, see the <a href="javadoc/index.html">Javadocs</a>, the <a href="impl/index.html">Implementation details</a>. Also, sometimes a running program is better than any documentation; you can experiment with PrettyProlog as a <a href="applet.html">Java applet</a>.
	</p>
    </div>
    <div id="footer"><a href="index.html" id="linktothispage">General info</a> | <a href="javadoc/index.html">Javadocs</a> | <a href="impl/index.html">Implementation details</a></div>
</div>
</body>
</html>